Invite a friend: referral attribution across the analytics stack - #5751

Adds com.codename1.analytics.invite: mint an invite link, share it through
the native share sheet, and on the invited device recover the invite that
caused the install. Resolved attribution is written as persistent analytics
dimensions, so every later event -- including the purchase event the
framework already emits -- carries the campaign and the referrer.

The package boundary is load-bearing, not cosmetic. The PlatformFeatureCatalog
entry that buys the Play Install Referrer library also raises the application's
minimum API level to 21, and the catalog matches on a package prefix. Keyed one
package higher it would match com/codename1/analytics/Analytics, which nearly
every application references, and put that dependency and that floor on all of
them -- the DatabaseConfig failure AndroidGradleBuilder.usesClass records, which
deleting the unused sources later does not undo. Two tests pin the boundary and
were confirmed to fail when the prefix is widened.

Analytics.java is not modified. resetClientId() does not clear custom
dimensions, which is right for an application's own dimensions but would leave
the referral dimensions behind and re-link a fresh pseudonymous id to the same
inviter. InviteAttributionProvider observes the client id through the init
callback Analytics already makes, and erases only the referral dimensions.

Five review findings and fifteen PMD violations.

Consent: a restart before the user answered the prompt destroyed the deferred
profile. Analytics.addProvider synthesizes AnalyticsConsent.denied() for the
null state, and this provider is registered on every facade entry, so a second
launch before any choice arrived looking exactly like an explicit refusal --
deleting the profile captured on the first launch and moving to DECLINED, from
which a later grant could never resume. The provider now asks
Analytics.getConsent(), which returns null until a real choice is on record,
instead of believing the argument.

Outbox: entries were cleared at send time, so a registration that never landed
was never retried. The registration carries the campaign, channel, payload and
preview metadata, and a click cannot reconstruct any of it -- and the case that
lost it is the offline mint, which is the reason minting is offline at all. Each
entry is now retired by its own successful response.

flush() only drained registrations. A deferred lookup that failed because the
first launch was offline left deferredStarted set with nothing to clear it, so
the documented connectivity-recovery call silently left the attribution
unresolved until the next cold start. It now restarts the pending lookup, still
bounded by the persisted attempt counter.

Custom parameters did not survive a restart, so an answer that arrived before
the listener registered was delivered on the next launch stripped of the data
the app acts on. They are serialized into the durable record.

Invite.isRegistered() could never return true: the value is captured when the
invite is minted and registration completes asynchronously afterwards, so the
flag could only ever report what it was constructed with, contradicting its own
documentation. Removed, and replaced with Invites.isRegistered(Invite), which
reads the outbox and can actually answer.

PMD: redundant public on interface methods, six indexed loops, two missing
@OverRide. The two NonThreadSafeSingleton findings are lazy-init caches, not
singletons; they are guarded by a load flag rather than by a null check on the
field, which is both what PMD wants and more correct -- "no attribution" and
STATE_NONE are real answers, so a null check would re-read storage on every call
for the uninvited majority. No locking was added: this facade runs on the EDT.

6,649 tests pass, SpotBugs 0, PMD 0 on the invite sources.

…r read

Six findings on this PR, all valid.

The client never read invite.domain. The builders generate the Android intent
filter and the iOS associated domain from that hint, but getLinkBase() only ever
consulted cloudServerURL and the default -- so an app that set a custom host
minted links for cloud.codenameone.com while its own app-links registration
named something else, and the installed app never opened its own links with
nothing reporting an error. Both builders now stamp the resolved host into the
app and the client reads it, so the two cannot disagree.

The deferred profile was written before the consent check. pendingRecord()
persists on the spot and onConsentChanged only deletes a record that already
exists when it runs, so a user who had ALREADY refused got a profile written on
their next launch and it stayed indefinitely -- contradicting the documented
promise that a refused profile is deleted. An explicit refusal now writes
nothing at all. An unset choice still captures, which is the point: the match
window closes long before a prompt is answered.

A terminal no-match was not durable. resolved:false only updated memory, so
loadState() resurrected the lookup on every launch and an ordinary uninvited
install re-queried the server and re-fired attributionUnavailable for ever.

Storage.writeObject's result was ignored. Storage was chosen over Preferences
precisely because it reports a failed write; deleting the pending record after
one left neither an attribution nor any retry information.

Re-attribution left stale dimensions: a later invite with no campaign kept the
previous one, so events carried the new code beside the old campaign.

A transient Play Store failure burned the once-only flag, so a later flush
skipped the deterministic referrer for ever and fell back to a guess. Only
terminal outcomes are recorded now.

One test failed and deserved to. It used AnalyticsConsent.none() to mean "not
decided yet", but none() is an explicit refusal; the fix exposed that the test
encoded the wrong semantics. Split into undecided (null) and refused.

Vale caught what a narrower local run did not: the build hint doc strings are
rendered into the generated guide table and linted there. Fixed at source; the
whole guide is clean across 123 files.

6,650 tests pass, SpotBugs 0.

Four findings, all valid.

A response already on the wire could undo a privacy operation. When consent is
withdrawn or resetClientId() runs, both delete the pending record and clear the
referral dimensions -- but the claim or match request they raced still arrived,
and resolve() wrote the attribution and dimensions straight back under the fresh
identity. Every lookup now carries the epoch it was issued under and a response
whose epoch no longer matches is dropped, with the permission re-checked as
well. Two tests cover it.

The direct-link path had no denial guard. The earlier fix put one in
beginDeferred(), but checkForInvite() treats a consumed URL as handled and skips
that entirely -- so a refused user opening an invite link still had a profile
persisted, by the other route. Same guard, both entry points.

The outbox cap silently discarded unacknowledged registrations. Once entries
were retired on acknowledgement rather than at send time, evicting the oldest
became a way to lose an invite whose link had already been shared: the code
carries no inviter, campaign, payload or parameters, so a later click can never
be joined to any of it. The ceiling is now 512 rather than 32, and breaching it
is logged rather than silent. I am keeping a ceiling -- an unbounded on-device
queue is not something to ship -- but it is now far outside anything the design
contemplates.

The Android filter claimed every invite link on the shared domain. This is the
Android twin of the apple-app-site-association collision the slug already solves
on iOS: a bare /i/ prefix makes every invite-enabled app an eligible handler for
every invite url, so Android shows a chooser or opens the wrong app, and the
slug inside the path cannot disambiguate because the filter accepts them all.
The new invite.slug hint scopes it to /i/<slug>/. Without a slug the broad
filter is still emitted and the hint documents why -- a filter matching nothing
would be worse.

6,652 tests pass, SpotBugs 0, the whole guide is Vale-clean.

A non-2xx response reached postResponse() exactly as a 200 did --
ConnectionRequest reads error bodies by default and the error path falls
through -- so a transient 5xx retired the durable registration as though the
server had accepted it, and an error body parsed as "not resolved" turned one
bad minute upstream into a permanent "you were not invited". Gate both on the
status.

The build scoped the Android filter and the iOS path claim to /i/<slug>/ but
only stamped invite.domain into the app, so the client learned the slug from
the link service -- which the first invite is minted before ever reaching. That
first link could not match the build's own filter. Stamp the slug too, and let
it outrank the stored value.

A terminal no-match deleted the pending record, and an absent record reads back
as STATE_NONE: the next launch built a fresh profile and asked again, for ever.
Replace it with a marker that carries the state and nothing else -- durable, and
holding none of the profile, which existed to be matched and now has nothing to
match against.

Under re-attribution a pending claim lost to the older resolved attribution in
loadState(), so a claim interrupted by process death was never retried and last
touch silently kept losing to first. Consult the pending record first, and only
under re-attribution: without it a stale record must never reopen a settled
attribution.

The manifest filter was suppressed by any existing filter naming the host, so an
app already routing cloud.codenameone.com/account/ never got one and its invite
links kept opening the browser. Require the path too, and accept only a prefix
that really covers /i/<slug>/.

InviteStore.writeOutbox discarded writeObject's result, so a full store lost the
campaign, channel, payload and preview of a link already handed out with no
sign. Propagate it and send that one registration immediately instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

A Play Install Referrer outage is not an answer. Two failed connection attempts
left the source's once-only flag deliberately unset so a later launch could read
the exact referrer, and then the statistical fallback's no-match settled the
install as organic anyway -- throwing away a deterministic result that was still
reachable. A transient failure now marks the record, and a no-match against that
mark stays pending, bounded by the attempt cap and the window as before.

setAttributionWindow(0) recorded nothing: setState() only rewrites a record that
exists, and on a fresh install none does, so the listener heard "unsupported" on
every launch. It writes the terminal marker now -- the one marker that carries a
reason, because it is the only terminal answer that can stop being true, and an
application that later ships a non-zero window is asking for attribution again.

The filter check searched the whole hint value, so a filter for our host on
/account/ and an unrelated host on /i/ claimed coverage between them although
neither would ever open an invite link. Host and path are matched within one
<intent-filter> now.

isRegistered() read absence from the outbox as acknowledgement, which is exactly
wrong for the registration sent directly because the outbox could not be written:
never queued, so the queue says nothing about it. Those codes are tracked in
memory until the server acknowledges them -- in memory because the durable store
is the thing that failed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…al one

A deferred lookup already on the wire ran under the same epoch as the direct
claim that superseded it, so both answers passed the guard and a statistical
match arriving second overwrote the exact one -- its dimensions and its durable
record with it. The direct claim advances the epoch, which is how every other
supersede in this class is expressed.

The pending branch added last round still called attributionUnavailable(), which
is the terminal callback: it says no invite will be attributed, and it sets
deliveredThisRun, so a referrer that succeeded moments later in the same process
could no longer deliver inviteReceived() -- while a relaunch could deliver it as
a second outcome after the first said never. A pending outcome now tells the
listener nothing.

Refusing consent deleted the pending record and then called setState(), which
has nothing to rewrite once the record is gone, so STATE_DECLINED lived in memory
and the listener was told again on every launch. It writes the profile-free
marker instead, at all three refusal sites. The marker carries its reason, and
beginDeferred reopens it when the reason stops being true -- a granted consent
here, a re-enabled window for the other one -- read from the condition itself
rather than from a second stored copy of it.

A successful referrer read carrying no invite is definitive, and it left an
earlier outage's referrerRetry marker in place, so the following no-match looked
retryable and every launch asked again until the attempt cap. The non-retryable
path clears it.

Two consent tests asserted the record was absent, for a promise that is about the
profile. They assert the profile fields are gone now, which is the property the
documentation actually makes and the only one that can survive a relaunch.

Also fixes the PMD NonThreadSafeSingleton that build-test (8) caught in
loadState: the record is reduced to a value before the branch, so there is no
null-check-then-static-assign shape. Not a lock -- this facade runs on the EDT
and adding one would be the real mistake.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Two review findings, plus two defects of my own found while verifying them.

reset() threw away resetVerified()'s answer. The detection added last round
was real and then dropped at the one call site an application reaches, so a
PENDING record that outlived its erasure was still claimed on the next
launch and a surviving outbox entry still went out under the old client id.

It latches the gate now -- but only when something really did survive.
resetVerified() also answers false for a reason that leaves nothing behind,
no Storage at all, and latching on that would block a device with no invite
data to block over: nothing else proceeds until an erasure succeeds, and
that is a severe consequence to hang on a device state.

The mirror image was also wrong, and was mine from the previous commit:
only eraseInternal() ever cleared the flag, so a plain reset() that
SUCCEEDED left a stale latch standing, and the next gated call then ran a
full erasure -- tombstone included -- turning an ordinary reset() into a
terminal state the application never asked for. A successful reset clears
it, which is what the flag has always claimed to mean.

The tap time is kept now. An App Clip invocation is resolved by iOS from
the association file, so it never reaches our redirect: the clip is the
only witness, and the native side clears the handoff as it reads it.
Dropped in the callback it was gone, and getClickTimestamp() answered zero
for every App Clip attribution. It is persisted in the pending record --
the claim can fail and be resent from there -- and sent as clickedMillis.

The Play referrer had the identical bug and the finding did not mention it:
onReferrer carries clickSeconds and nothing read it either. Fixed together,
because fixing one platform and not the other leaves the two reporting the
same field differently, which is worse than both being wrong.

Asserted as a bare JSON number rather than a quoted one, because the server
binds it to a long: a string coerces today and stops the moment anything
there gets stricter.

And the PMD gate caught five violations I had pushed: PATH_MATCH left
behind by the deleted /match endpoint, and four missing @OverRide on the
App Clip callback, which the install-referrer callback directly above it
has. I had been skipping the static-analysis gates locally because SpotBugs
will not run under this JDK; PMD does, through pmd:pmd, and it is clean now
-- verified by injecting an unused field and confirming it is reported,
because a report that is empty because nothing was analysed looks exactly
like one that is empty because nothing is wrong.

…later

resetClientId() clears the reserved cn1_ dimensions, and Preferences.set
discards its own write-failure boolean -- the same trap Continuity documents
and the reason Invites uses Storage instead. So on a full or read-only
store the entries vanished from the in-memory map and stayed in the file,
and the next launch loaded them back and attached the referral identity the
user asked to be rid of to their NEW client id. One launch later, with
nothing in memory left to notice.

Two halves, because each closes a case the other cannot.

persistDimensions() reports now, by reading the value back rather than
trusting the write, and clearReservedDimensions() retries once on failure.
That closes it inside the process, where the cause is usually transient.

Across a restart no in-memory retry survives, so the persisted blob is
stamped with the client id it was written under. loadDimensions() drops
reserved entries whose stamp names an identity that has since been reset --
the erasure finishing late -- and keeps the APPLICATION's own dimensions,
because those are not what an erasure asked about and losing a plan or role
the app set would be a second bug in the name of fixing the first. An
absent stamp reads as current, so a file written before this existed is not
discarded.

Both directions are pinned: a stamp from an erased identity drops only the
cn1_ entries, and a stamp from the CURRENT identity keeps them -- without
that second test the drop could be keyed on the prefix alone and throw the
referral away on every ordinary launch. The first was revert-probed: with
the check disabled the test reports the erased campaign coming back as
"spring", which is the bug exactly.

…raps

The verification from the previous commit was worthless and I should have
read Preferences before writing it. Preferences.set updates a static
Hashtable and Preferences.get reads that same Hashtable, so comparing a
value with what comes back compares memory with memory: it reports success
for a write that never reached the disk.

It was worse than useless. persistDimensions() stamped the file with the
NEW client id in the same breath, so a failed erasure left the OLD reserved
dimensions sitting under a stamp that claimed them as current -- and the
stamp, which is the mechanism that was supposed to catch exactly this, said
they belonged. The fix made the bug harder to see.

The check is gone, with a note saying why it cannot work, and the stamp now
carries the whole job. An ABSENT stamp counts as foreign rather than
current, which is the difference between a mechanism that works and one
that works only when the write it depends on succeeded: on a device whose
file predates the stamp, or where the same storage failure that broke the
erasure also stopped the stamp landing, there is nothing to compare. The
trade is explicit -- a reserved dimension dropped wrongly is rewritten by
the next attribution; an erased identity coming back is not recoverable --
and clientId() is used rather than the field, because loading can happen
before the id is materialised and a null made every file look current.

ios.invite.appClip=false disabled the receiving side too. It means "do not
GENERATE a clip", which is what a developer sets when they ship one of
their own -- and it was suppressing the app group, the native define and
the registration of IOSAppClipHandoff along with it, so a custom clip wrote
the documented handoff into the documented container and nothing read it.
Generation and reception are separate questions now, and the hint's
documentation said the wrong thing too.

The clip also hard-coded TARGETED_DEVICE_FAMILY=1, on the belief that App
Clips do not run on iPad. They do -- and an ios.project_type=ipad build has
an iPad-only app target, so an iPhone-only clip inside it shares no family
with its container and App Store validation rejects the archive. It uses
the same host-family helper every other embedded target here uses.

InviteStore.delete() overwrites a record it could not remove with an empty
one, deliberately: an empty record carries no code, no inviter and no
campaign, so a delete that cannot happen at least leaves nothing behind.
But the state read defaulted an absent "state" key to STATE_PENDING, so
that tombstone came back as a pending lookup -- and under re-attribution a
pending state outranks the durable attribution, so the settled claim was
resubmitted and invite_install or invite_opened counted one install twice.
An empty record reads as absent now.

And the class documentation still told applications that this feature
writes a coarse device profile -- OS version, hardware model, language,
screen size -- to local storage before consent. It has not since App Clips
replaced the statistical match: pendingRecord() stores timing and state,
and the code it keeps is one the person produced by tapping an invite.

That is worse than a stale comment. It is the paragraph a developer copies
into their own privacy disclosure, so leaving it there publishes a claim
about data collection that does not happen -- and it would reasonably put
someone off the feature entirely. It now says what is actually stored.

delete() falls back to overwriting a record it cannot remove with an empty
one, and the previous commit stopped that empty record reading as pending.
This is the case where BOTH fail: the real pending state survives beside
the new attribution, and under re-attribution loadState() prefers it --
deliberately, so a claim interrupted by process death is retried. The
already-successful claim was therefore resubmitted on the next launch, and
a second invite_install or invite_opened was emitted for one install.

The record is overwritten with the terminal state when the delete fails.
That says what the deletion would have said, in a record the store has just
proved it will not remove, and it carries no code and no inviter -- so if
that write fails too, what is left is the record that was already there and
nothing new is disclosed. The failure is logged rather than assumed away.

Revert-probed: with the check removed the test reports the settled install
coming back as pending, which is the resubmission exactly.

ios.invite.buildSettings.PRODUCT_NAME can override what the clip is built
as, but the embed reference looked for CN1InviteClip.app in
BUILT_PRODUCTS_DIR regardless -- so such a build failed while copying a
product that was never produced.

It goes through effectiveExtensionProductName, the same helper the VPN
tunnel and Matter targets use, which also refuses a value this build cannot
evaluate rather than emitting a reference that cannot resolve: an Xcode
condition is legal in that setting and nothing here can expand it, so the
honest answer is to say which hint is unusable and why.

Outbox entries leave the queue only when their OWN response acknowledges
them -- which is right, because the campaign, channel, payload and preview
cannot be reconstructed from a click -- but that leaves an entry drainable
while its request is still outstanding. create() flushes unconditionally,
so N invites minted in a burst sent N(N+1)/2 requests: six produced
twenty-one, and the 512-entry cap puts a full queue past 131,000.

Entries now carry an in-flight mark, and the two flushes are told apart.
create()'s own flush skips what is already going out; the PUBLIC flush()
does not, because it is documented as the "I have just regained
connectivity" call and its whole job is resending a request that went out
over a dead network and will never answer. An existing test pins that
second behaviour and caught the first attempt, which suppressed both.

The mark is released on every outcome, including handleException -- where
postResponse() never runs. Without that a transport failure left the entry
marked for the life of the process and no later drain retried it, trading
an amplification bug for a lost registration, which is the worse of the
two. It is not persisted, so a process that dies with requests outstanding
retries them on the next launch.

And ios.invite.universalLinks=false disabled the receiving side, exactly as
ios.invite.appClip=false did before it. It means "do not inject the
associated domain, I manage the entitlement myself" -- and it was also
suppressing the app group, the native define and the registration of
IOSAppClipHandoff, so an app that had configured its own domains correctly
had nothing reading the handoff and every iOS install settled as no_match.
Each hint is applied where the thing it governs is done, and neither gates
the machinery any more.

All three are the same shape, and it is the shape Preferences forces:
`set` updates a static table and swallows the store's answer, so no write
to it can be verified. Everything durable that CAN report -- the three
InviteStore records -- already does. These are the places that trusted the
other kind.

reset() cleared the referral dimensions in memory and asked Preferences to
persist that, while resetVerified() reported success on the records it can
verify. A plain reset keeps the same client id, so the owner stamp still
matched and the next launch loaded the old cn1_invite* values back and
transmitted them, despite reset() promising to forget them.

The attribution record is the authority and it IS verifiable, so the
dimensions are reconciled against it once per process: if no record stands
behind them, they are the stale copy and the erasure finishes on the next
launch instead. That is the best an unverifiable store allows, and it is
self-healing rather than dependent on the failing write ever succeeding.

The provider's identity baseline had the mirror problem. A failed baseline
write leaves the same empty value a first registration does -- so the next
resetClientId() in that process read the new id as its first baseline,
skipped eraseInternal(), and left the old attribution and the queued
registrations attached to the identity just reset. Records with no baseline
are treated as the erasure that never completed; a device with no records
is the genuine first registration it looks like.

And when both the PENDING delete and its settled-marker replacement failed,
the held fallback was discarded anyway -- committing the resolution with a
durable STATE_PENDING on the disk, which re-attribution prefers, so the
next launch resubmitted a claim that had already succeeded. The fallback is
kept when its own write failed, so the next read retries it.

The first is revert-probed: without the reconciliation the test reports the
erased campaign still reading "spring".

CN1InviteAppClip.m put both native implementations behind
CN1_INCLUDE_INVITE_APPCLIP, but IOSNative.java declares the methods
unconditionally -- and ParparVM needs a symbol for every native declaration
whether or not anything reaches it. So an ordinary iOS application that
never heard of invites would have failed to LINK, on a feature it does not
use, which is the worst possible place for this to be felt.

I reasoned that dead-code elimination would drop the unreferenced Java
methods along with the class nothing registers. That was wrong, and the
file next door says so in as many words: CN1WebAuthn.m supplies #else stubs
for exactly this reason and explains it. This now does the same, answering
what a device with no clip answers anyway, so nothing depends on which
branch compiled. Verified by compiling the file with the define OFF.

SERVICE_DISCONNECTED arriving as a RESPONSE CODE fell into the terminal
default, which records PREF_ATTEMPTED and refuses another read for ever. It
is the same transient state the disconnect callback reports, and handling
that callback -- as this branch already does -- does not cover this path:
an invited install whose exact Play referrer was still available on the
next connection settled permanently as organic. It takes the transient
route now, so the once-only flag stays unburnt.

… upload

ASSETCATALOG_COMPILER_APPICON_NAME was blanked on the clip target. An App
Clip is a full application bundle and App Store validation rejects one with
no icon, so every invite-enabled iOS archive would have been refused at
upload -- for a target the developer never asked to maintain and cannot
fix from their own sources.

The host's Images.xcassets is copied into the clip rather than a
placeholder generated: a clip card showing a different icon from the app it
installs is its own confusion, and the person seeing it has installed
nothing yet. appendFilesToXcodeProjGroup already adds an .xcassets
directory as a single resource -- it has to, or Xcode fails with "Multiple
commands produce Contents.json" -- so staging it is all that is needed. A
build with no host catalog says so rather than naming a catalog that is not
there, which would fail the build instead of the upload.

The derived product name went into a single-quoted Ruby literal unescaped,
so a legal PRODUCT_NAME containing an apostrophe -- "Friend's Clip" --
broke fix_xcode_schemes.rb and the iOS build with it. It goes through
escapeRuby like every neighbouring target.

And the ios.invite.appClip documentation still said it was ignored when
ios.invite.universalLinks is false. That stopped being true when the two
hints were separated: universalLinks now means "I manage the domains
myself" and leaves the clip, the app group and the reader in place, so a
developer relying on the old wording would get a second target and its
signing requirements unannounced. appClip=false is the only thing that
suppresses generation, and the entry says so.

markTerminal() copies the code provenance into the reopenable DECLINED
marker so a user who refuses consent when the link arrives and grants it
afterwards keeps their exact claim. codeClicked was added to the record
later and never added to that list, so a withdraw-then-grant cycle resent
the claim with a zero time -- and for an App Clip that time is
irrecoverable, because the invocation never reaches the redirect and the
clip cleared its own copy as it was read.

The clip handoff also charged the retry budget twice: the local read bumped
attempts and the claim it leads to bumped them again, so the first network
claim started at 2 and the install settled terminal after four requests
instead of the five MAX_ATTEMPTS promises. The install-referrer path never
bumped there, so the clip path was the inconsistent one; both now spend the
budget only on network attempts, and a source that answers nothing at all
is bounded by the attribution window on both.

And the SpotBugs finding CI caught: a redundant null check on
Analytics.getDimensions(), which returns a fresh copy and never null.

That gate has been blind on my side all branch -- SpotBugs will not run
under the JDK 8 toolchain, so I had been passing -Dspotbugs.skip=true. It
runs under JAVA17_HOME, and the recipe needs stating because two earlier
attempts reported clean without running at all: the report has to be
DELETED first, and the run needs network access or checkstyle fails in the
validate phase and spotbugs never executes, leaving the previous report to
be read as success.

…leased

erasurePending is a static, so a reset() whose deletes failed and whose
application then exited left nothing to retry from -- and a plain reset
keeps the client id, so the provider sees no identity change on the next
launch and does not erase either. The surviving attribution came back and
was transmitted, which is the one thing reset() promises cannot happen.

There is a durable ERASURE record now, picked up once per process before
anything can read or transmit. It is a WRITE recording a failure to DELETE,
which is deliberate: a store refusing removals may still accept a small
write, and if it refuses that too this is no worse than what came before.
Revert-probed -- without the resume the test reports the erased attribution
coming back.

The in-flight mark was released by a callback that never runs. These
requests are fail-silent, and NetworkManager's fail-silent branch only logs
-- it never calls handleIOException or handleRuntimeException, so nothing
reaches the request's own hooks. A transport failure left the entry marked
for the life of the process and every automatic drain skipped it, trading
an amplification bug for a registration only an explicit flush() or a
restart would resend. It is a 60-second time bound now: a burst happens in
milliseconds, so the bound serves the original purpose completely while
guaranteeing the queue heals, and expired marks are dropped as they are
read.

The Play referrer's one-shot flag was burnt before the code was handed
over, so a process killed in between lost the exact referrer for ever and
the next launch settled the invited install as no-match. The handoff comes
first now.

Being precise about what that buys: Invites marshals onto the EDT, so a
callback arriving on a binder thread has its persist QUEUED rather than
done. The window goes from always to the callSerially latency, not to zero.
Closing it completely would need the port to know what the framework did
with the value, which the SPI deliberately does not tell it.

And DM_NUMBER_CTOR on the new map -- new Long() where Long.valueOf()
belongs. Caught by running SpotBugs locally this time rather than by CI.

…dimensions

Three review findings, each a case the code got wrong in a way nothing
reports.

The warm-link path stored a data-less COPY of the intent. That fixed one
reader -- an onNewIntent() override reading the intent it was handed -- and
broke two others: the documented `android.intent.data` property is published
from whatever the activity has stored, and native integrations read
getActivity().getIntent().getData(). Both saw a warm deep link as no deep
link at all while cold links still carried it. The intent is now stored
unmodified and the url is marked delivered by remembering the intent's
identity, which suppresses only getAppArg()'s second delivery.

Dimension files with no owner stamp are adopted rather than dropped. An
absent stamp means the file predates the stamp -- persistDimensions() writes
both keys into one preferences record -- and back then setDimension()
reserved no prefix and the framework wrote no `cn1_` dimension, so anything
with that prefix in such a file is the application's own and dropping it
deleted segmentation from an app that never asked for an erasure. A stamp
that is present and different is still foreign. The reserved prefix is now
documented on setDimension() rather than only on resetClientId().

abandonReplacement() verifies the deletion, like the resolved path already
did. Ignoring it left the replacement's PENDING record on disk while memory
moved on to RESOLVED, and loadState() prefers a surviving pending record --
so a claim that had already ended definitively was resubmitted every launch,
for ever. The second, open-coded copy of that abandonment now calls it.

Both behaviour changes are covered by tests verified against the unfixed
code; the unused `pending` parameter PMD flagged is gone with it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

beginDeferred() runs at most once per process, which is right for the first
attempt and wrong for every later one. The lookup is fail-silent, so a
request that never answered leaves deferredStarted set with nothing to clear
it, and a claim answered with "retry" -- the ordinary state of an invite
minted offline, whose registration has not landed yet -- is pending with no
attempt outstanding. Either way the documented call-me-from-start() contract
did nothing for the rest of the run: the invite resolved on the next cold
start, after an onboarding that could have had its payload, its callback and
its dimensions.

checkForInvite() now re-arms a pending lookup with nothing in flight, which
is what flush() already did for the regained-connectivity case. Bounded by
lookupInFlight(), so an application that calls it from every form cannot
spend the attempt budget faster than one attempt per retry interval, and by
the persisted cap and the attribution window beyond that. The contract is
documented on the method rather than left to be discovered.

The plugin's source-level test asserted the intent-copy shape that the
previous commit replaced, and failed build-test (8) and build-linux-jdk8 on
exactly that. It now asserts what replaced it: the stored intent keeps its
data, the url is marked delivered by identity, and getAppArg() honours the
mark.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

reconcileDimensions() only ever reconciled one way. It dropped reserved
dimensions with no record behind them, and accepted whatever the dimensions
said whenever a record existed -- so it never noticed the opposite failure.

Preferences.set swallows its write failure, so a resolve can commit the
attribution and fail to persist the four dimensions: correct in memory for
the rest of that process, and gone on the next launch. Every later batch then
carried no campaign at all, or -- under re-attribution, where the previous
invite's values are still on the disk -- the campaign the install no longer
belonged to, crediting its revenue to the wrong cohort. Nothing looked again,
because the only thing that could have was satisfied by the record existing.

The record is the half that can report whether it was written, so it is the
authority: when the persisted dimensions disagree with it they are rewritten
from it. Compared first, so an ordinary launch does not pay for a storage
write it has no use for. Verified against the unfixed code, where the test
sees the previous campaign survive a resolve that replaced it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>